1. Field of the Invention
The present invention relates to a method and system for protection switching in an Ethernet ring and, more particularly, to a method and system for supplementing and improving a protection switching method in an interconnected Ethernet ring defined in ITU-T recommendation G.8032 Version 2.
2. Description of the Related Art
ITU-T recommendation G.8032 designates one of a plurality of links constituting an Ethernet ring as a ring protection link (RPL) and anode connected to one of both ports of the RPL as an RPL owner, so that the RPL owner can usually block the RPL to prevent a loop generation. Thereafter, if a fault occurs in links other than the RPL or from a node, the RPL owner may release the block state of the RPL and initialize a filtering database (FDB) of each node to allow service traffic to be transferred via a new path (route) formed through MAC address learning.
Since the stipulation of the ITU-T recommendation G.8032 Version 1, version 2 has been in the course of development since October 2008. While G.8032 Version 1 only defines protection switching within a single Ethernet ring, G.8032 Version 2 includes a protection switching regulation for a case where two or more Ethernet rings are interconnected.
Ethernet rings are interconnected by a shared node or a shared link. In the case of Ethernet rings interconnected by the shared node, when a fault occurs in the shared node, both Ethernet rings are isolated. Thus, interconnected Ethernet rings are generally configured by using the shared link to establish a reliable network.
FIG. 1 illustrates Ethernet rings interconnected by a shared link.
With reference to FIG. 1(a), one of certain links (referred to as ‘local links’, hereinafter), excluding shared links, may be designated as an RPL of each of first and second Ethernet rings. In the first Ethernet ring, a link a-j is designated as an RPL and a node ‘a’ is designated as an RPL owner, and in the second Ethernet ring, a link e-f is designated as an RPL and a node ‘e’ is designated as an RPL owner. Active topologies illustrated in FIG. 1 represent logical connections between nodes.
When a fault occurs in a local link, a pertinent Ethernet ring performs protection switching. With reference to FIG. 1(b), as a fault occurs in a link a-b, a local link, of the first Ethernet ring, the RPL of the first Ethernet ring is released to allow for a location connection among nodes in a new active topology.
However, if a fault occurs in a shared link and both Ethernet rings perform protection switching, the RPLs of the first and second Ethernet rings would both be released to form a super-loop as shown in FIG. 1(c), causing the entire network to be irresponsive due to broadcast storming.
Thus, in order to avoid this problem, the ITU-T recommendation G.8032 Version 2 currently under discussion stipulates that only a previously designated Ethernet ring perform protection switching when a fault occurs in the shared link. FIG. 1(d) shows the case where the first Ethernet ring is set by a manager to preferentially perform protection switching over the second Ethernet ring in the occurrence of a fault in the shared link, which does not form a loop unlike the case as shown in FIG. 1(c).
However, this method has a problem in that if another fault occurs in local links other than the shared link, the connections between the nodes of the Ethernet rings are cut off. As shown in FIG. 1(e), if a fault occurs in a local link and at the shared link of the first Ethernet ring which has been set to have a higher priority level, only the first Ethernet ring performs protection switching, resulting in a case in which the Ethernet ring is divided into nodes b-c-d-e and nodes f-g-h-i-j-a.
In addition, G.8032 only defines a recovery method for single fault as generated in Ethernet rings. However, if faults are generated from two places in a state wherein the two Ethernet rings are interconnected as shown in FIG. 1(e), although, in fact, each Ethernet ring has a single fault based on an arithmetic calculation, the current G.8032 cannot guarantee perfect connectivity between the nodes.